home *** CD-ROM | disk | FTP | other *** search
- Path: news.mpd.tandem.com!usenet
- From: Joseph Crowe <jcrowe>
- Newsgroups: comp.sys.amiga.misc
- Subject: Re: OS features
- Date: 8 Jan 1996 22:07:46 GMT
- Organization: Tandem Computers,Inc. (Austin, TX)
- Message-ID: <4cs4ji$rou@news.mpd.tandem.com>
- References: <92747544038@PAPA.NORTH.DE> <4b3h9s$1st@alterdial.UU.NET> <2152.6561T63T2136@cycor.ca> <4b7i18$si1@vixen.cso.uiuc.edu> <oj6raxxrr0o.fsf@hpsrk.fc.hp.com> <13213431@sourcery.han.de> <4cp0un$cve@serpens.rhein.de>
- NNTP-Posting-Host: argyle
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 1.1N (X11; I; IRIX 5.3 IP22)
- X-URL: news:4cp0un$cve@serpens.rhein.de
-
- Hi Michael,
- mlelstv@serpens.rhein.de (Michael van Elst) wrote:
- >Protection is usually an asymmetric task. A (user)task must not corrupt data
- >structures used by other (user)tasks but a system library that manages
- >shared objects may corrupt data structures in (user)tasks. Reason is
- >that a shared library can be debugged more easily.
-
- I'm struggling to understand what you mean by the above paragraph. I don't
- find it at all desirable to have a system where an interface library can
- arbitrarily corrupt data structures in user task space. Could you relate this
- concept to a more concrete example?
-
- >
- >For interprocess communication one has to provide a new protected method.
- >Messages of non-trusted tasks may have to checked for consistency.
- >Again, for most applications we have one "server" that is shared among
- >several clients. The server can be made for error proof and thus is
- >allowed to corrupt client data. But the client must not corrupt server
- >data or the data of other clients.
-
- Are you saying that some sort of object server should be allowed to
- arbitrarily corrupt an instantiation of a client or even an inherited object in
- the client tasks memory area? Not in any OS I'd ever own.
- >
- >Anyway, before you can think about memory protection you have to solve
- >resource tracking. There are some difficulties involved, mainly in
- >arbitration of shared objects (or rather the lack of arbitration).
-
- True....the UNIX method of solving this problem works OK, even if it is sort
- of ugly and not too elegant. Essentially, security is provided by the standard
- UNIX ownership mode bits. For shared memory, give some range that is set up by
- a task with a shared memory ID, there is the concept of owner, group and others
- and permissions to read and/or write. Once it is set up, the owner task can
- even exit while the shared memory segment remains. Other tasks, if they have
- the correct permissions, may attach the shared memory and it then gets mapped
- into their address range. Other IPCs work in a similar manner. To implement
- something similar in an OO environment should not be too difficult. It would
- still allow memory protection for task/process addressability and even would
- result in a SIGSEGV(in UNIX speak), if a task attempted to write outside the
- range of the shared memory it had attached.
- >
- >> That's an idea. I have seen similar under BeOS which can put contiguous
- >>memory regions together from fragments.
- >
- >With virtual memory the fragmentation exists in the virtual address
- >space. The effect of this fragmentation is small because the virtual
- >address space is much larger and because virtual addresses are allocated
- >with a rather coarse granularity. Fragmentation smaller than the page
- >size just affects one task and is effectively removed when the task
- >ends.
-
- With demand paged VM, there's often multiple sizes of allocation units, at
- least, once you leave user space. Even with the limitation of a single size of
- page, it amounts to a win because pages of data, instructions, stack, buffer
- cache etc., will only exist in physical memory when needed and will only stick
- for as long as they are frequently accessed, depending on the page-aging
- algorithm. Most shared library implementations in UNIXland will not even bring
- in a single page of a shared library until a page fault occurs attempting to
- access and instruction from that library. Same goes for any other instructions
- on the user side of the system call interface. It's not perfect, or people
- like me would not be employed....;^)....but it's fairly effective when compared
- with a non-protected environment.
- >Separated address spaces for each process are even better because
- >the total address space now grows with the number of processes. But
- >this approach costs a lot in compatibility. It might be possible
- >to use partially separated adress spaces though in new programs.
-
- Maybe for data, but please do not blow off re-entrant shared code.
- >
- >Regards,
- >--
- > Michael van Elst
- >
- >Internet: mlelstv@serpens.rhein.de
- > "A potential Snark may lurk in every tree."
-
- --
- Joseph Crowe
- jcrowe@isd.tandem.com
-
-